EuroCD 3/EuroCD 3.iso/Communication/Citadel_BBS/Docs/network3.man

Text File | 1998-06-24 | 115KB | 2,501 lines

                         C I T A D E L - 8 6

                                V3.41

                            NETWORK MANUAL

                        Copyright 1989 - 1991

                             by Hue, Jr.

                        C-86 Test System Sysop

                               91Dec08














































                             TABLE OF CONTENTS

     I. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1
     II. Compatibility Ishes . . . . . . . . . . . . . . . . . . . . . . 1
     III. Functionality  . . . . . . . . . . . . . . . . . . . . . . . . 2
          III.1 Normal User Capabilities . . . . . . . . . . . . . . . . 2
          III.2 Aides and Citadel-86's net . . . . . . . . . . . . . . . 3
          III.3 Sysop Capabilities . . . . . . . . . . . . . . . . . . . 4
                III.3.a Node Creation  . . . . . . . . . . . . . . . . . 4
                III.3.b Node Administration & Member Nets  . . . . . . . 5
                  III.3.b.i Special Access Strings . . . . . . . . . . . 5
                  III.3.b.ii Baud setting  . . . . . . . . . . . . . . . 5
                  III.3.b.iii Condensed Names  . . . . . . . . . . . . . 5
                  III.3.b.iv Download Toggle . . . . . . . . . . . . . . 6
                  III.3.b.v External Dialers   . . . . . . . . . . . . . 6
          III.3.b.vi Fast Transfers
                  III.3.b.vii New Node ID  . . . . . . . . . . . . . . . 6
                  III.3.b.viii Kill System . . . . . . . . . . . . . . . 6
                  III.3.b.ix Change Local/LD setting . . . . . . . . . . 6
                  III.3.b.x Change Name  . . . . . . . . . . . . . . . . 6
                  III.3.b.xi Network Passwords . . . . . . . . . . . . . 6
                  III.3.b.xii Room List  . . . . . . . . . . . . . . . . 7
                  III.3.b.xiii Member Nets . . . . . . . . . . . . . . . 7
                  III.3.b.xiv Spine Settings . . . . . . . . . . . . . . 7
                III.3.c User Administration  . . . . . . . . . . . . . . 7
                III.3.d Normal Shared rooms  . . . . . . . . . . . . . . 8
                III.3.e File Requests  . . . . . . . . . . . . . . . . . 8
                III.3.f Sending Files  . . . . . . . . . . . . . . . . . 9
                III.3.g Priority Net Mail  . . . . . . . . . . . . . . . 9
                III.3.h Until Net Sessions . . . . . . . . . . . . . . . 9
                III.3.i Miscellaneous Net Menu Options . . . . . . . . .10
                III.3.j Advanced Room Sharing Options: Routing . . . . .10
                III.3.k Advanced Room Sharing Options: Virtual Rooms . .15
                III.3.l Advanced Room Sharing Options: Vortices  . . . .16
     IV. Networking and events . . . . . . . . . . . . . . . . . . . . .17
        IV.1 Member Nets . . . . . . . . . . . . . . . . . . . . . . . .17
        IV.2 Normal Network Sessions . . . . . . . . . . . . . . . . . .18
        IV.3 Anytime Network Sessions  . . . . . . . . . . . . . . . . .18
        IV.4 Until-Done Network Sessions . . . . . . . . . . . . . . . .20
     V. Domains in Citadel-86. . . . . . . . . . . . . . . . . . . . . .20
        V.1 What are Domains?. . . . . . . . . . . . . . . . . . . . . .20
        V.2 So how does Citadel-86 utilize Domains?. . . . . . . . . . .21
        V.3 Practical Notes and Procedures for all systems . . . . . . .21
        V.4 Practical Notes and Procedures for Domain Servers. . . . . .23
        V.5 RoutMail . . . . . . . . . . . . . . . . . . . . . . . . . .25
        V.6 Costing. . . . . . . . . . . . . . . . . . . . . . . . . . .26
        V.7 NodesX.* . . . . . . . . . . . . . . . . . . . . . . . . . .27
        V.8 Technical Notes. . . . . . . . . . . . . . . . . . . . . . .27
     VI. STadel mail routing . . . . . . . . . . . . . . . . . . . . . .27
          VI.1 Outgoing mail routing . . . . . . . . . . . . . . . . . .28
          VI.2 Incoming route mail . . . . . . . . . . . . . . . . . . .29
          VI.3 STadel considerations . . . . . . . . . . . . . . . . . .30
          VI.4 Notes . . . . . . . . . . . . . . . . . . . . . . . . . .30
     VII. CTDLCNFG.SYS Parameters. . . . . . . . . . . . . . . . . . . .30
     Appendix A: Other room-based Networks . . . . . . . . . . . . . . .31
     Appendix B: Temporary Files . . . . . . . . . . . . . . . . . . . .32
     Appendix C: Main C86Net . . . . . . . . . . . . . . . . . . . . . .32
     Appendix D: RoutMail.Exe  . . . . . . . . . . . . . . . . . . . . .33










     I. Introduction
        This manual talks about the functionality and usage of the Citadel-86
     Network. This is not a technical discussion of the transmission protocols
     used in the Citadel-86; for that discussion, please consult NETHACK3.MAN.

        We want to discuss what the Citadel-86 Network is capable of, and what
     you, the sysop, must do to use these capabilities.  As a relevant part of
     this discussion, we'll also tell you what it can't do.

        As a useful acronym/identifier, we are going to refer to the Citadel-86
     Network as C86Net throughout this documentation.

     II. Compatibility Ishes
        So, let's start with the vague topic of what we're compatible with.
     First the bad news: No, we do not talk directly to FidoNet.  Nor do we
     talk to a number of other networks, such as USENET, BITNET, etc, although
     there are utilities available that may allow you to hook into most nets
     through some programming effort on your part.

    C86net was designed, first, as a learning experience (so beware!), and,
     second, with room-based systems in mind.  Rather than attempting to use
     something designed with other purposes in mind, we decided to have fun.

        It is not impossible to talk to those networks in the future through
     the judicious use of the #event parameter and the labors of a captive
     programmer, and, in fact, the ability to talk to USENET is available.
     Since Paul Gauthier @Cerebral Cortex has disappeared, we're not sure
     who you should contact.  If you're interested in trying to connect to
     another net, investigate the MSGADD and MSGOUT utilities (see UTIL3.MAN).

        Now move to the good news.  Since STadel, as originally maintained by
     David Parsons of Pell, and now maintained by a cast of thousands, was
     originally derived from Citadel-86, it has maintained compatibility with
     C86Net, so you should be able to network with STadels and its derivatives
     in your area.  These derivatives include Fortress and Fnordadel.

        Amiga Citadel-68K, as maintained by Stallion (aka Jay Johnson) of The
     Phoenix, since it was also derived from Citadel-86, is compatible with
     C86Net.

        NeoCitadel, as maintained by Hue, Sr. of SuperComp III, is compatible
     with C86Net.

    Citadel-86e, maintained by Farokh Irani, can also network with
     Citadel-86 systems, although not all facilities are implemented.

        We should mention that when we say that software is compatible with
     C86Net, this means that a minimal network session can take place between
     the two pieces of BBS software.  Not all of the software mentioned here
     supports all of the functionality of C86Net.  Consult the documentation
     of the respective software for details.




                                   -1-






     III. Functionality
        So let's talk about what C86Net is capable of (this is the same as
     discussing what Citadel-86 is capable of).  First, to simplify this
     discussion, let's set up an "inheritance hierarchy" of users.  The
     bottom-most level will have certain capabilities on the network, the next
     level will have those capabilities plus several of their own, etc.
     Here's what we'll use:

              Sysops
                |
              Aides
                |
           Normal Users

        Each level, starting with the Normal Users, adds more capabilities.
     So we'll start with the lowest level, describing these capabilities.

     III.1 Normal User Capabilities
        Normal users have three capabilities on the network.

        First, they may send Mail> to users on other nodes of the network.
     C86Net Mail> can be sent by any user with network privileges to any local
     node, or if the user has Long Distance (LD) credits, to any LD node.

        The Mail> is entered by going to the Mail> room and typing .Enter
     Net-Message at the room prompt.  The user is then asked for the name of
     the system.  A '?' will elicit a list of systems that Mail may be sent to;
     an empty line will abort the .EN command.  If the user enters a legal node
     name, then the user is asked for the name of a user on the target system.
     An empty line will again abort the .EN command; any other input will be
     assumed to be the name of a user on the target system.  The user may then
     enter their message.

        In Section V we banter about the Sysop and Domains in C86Net.  However,
     we need to mention this here: the user can explicitly route mail to a
     domain.  The mechanism is to use .EN and when prompted for a system name,
     type

        <system name> _ <domain name>

        Your system will not attempt to verify the existence of the system at
     all; it will merely follow procedures mentioned below in Section V in the
     attempt to get the Mail to the specified domain.

        Due to both the volatility of the user bases of room-based systems and
     space considerations, user names cannot be validated during message entry.
     Therefore, Citadel-86 will try to validate the user name during the
     network session.  If the user has entered an invalid name for the target
     system, he will be notified via Mail> from Citadel of his/her mistake.

        A normal user's second ability is to enter messages in shared rooms.
     Shared rooms will be discussed in full in Section III.3; to summarize,
     they are rooms in which messages from your system can be sent to other
     systems, and messages from those system can be received. Normally, a user
     uses the command .Enter Net-Message to enter a message that should be sent
     to rooms on other systems; a normal Enter message will cause the message
     not to be networked to other systems (however, a shared room can be set


                                   -2-






     up so that all messages are networked -- see Section III.3).

        A shared room can be recognized by the blood-shot eyes of the sysop,
     and also by the fact that rather than having a '>' at the room prompt, it
     has a ')'.  A room that has a ':' for a room prompt is also shared, and
     also has a directory attached to it (which has nothing to do with the
     network).

        In both of the above cases, a normal message may be converted into a
     net message (when in an appropriate room) when saving the message by
     typing 'N' rather than 'S'.  A non-net message can be changed into a
     net-message by Aides who use the Pause-D facility and select the 'N'
     option from that menu.  Citadel-86 will then duplicate the message, make
     it into a net message, save it, and delete the original.  While this takes
     a little extra space in the system, it ensures the message will be netted.

         The third normal user ability is Local Mail> Forwarding.  This
     feature is useful in densely networked areas where users tend to have
     accounts on several systems, but do not have time to call all the systems
     daily.

         Local Mail> Forwarding allows the user to specify that Mail> sent
     to the user locally should be forwarded to another system.  Mail> sent
     to the user will then be converted to C86Net Mail>, with one copy being
     sent to the user's account on the system specified, and one copy being
     left in the Mail> on the local system, in case the user should login at
     a propitious moment.  The user may optionally specify the Mail to be
     forwarded to a different alias on another system.

         In order for a user to have access to this feature, the user must
     must have net privileges.  If the user specifies forwarding to a LD
     system, the user must have LD credits, or the Mail> will not be forwarded
     (thus making forwarded Mail> their financial responsibility, rather than
     the sender's).

         Mail> Forwarding is accessed via the .Enter Configuration
     Address command.  The user will be asked for a system to forward his/her
     Mail> to.  If they wish, they may use a domain-specified system.  A
     blank line will cancel Mail> Forwarding.  Then the user will be prompted
     for an alias to deliver the Mail> to.

         Mail from the Sysop to Citadel will never be Forwarded.  However,
     unlike earlier versions of Citadel-86, incoming Network Mail will be
     forwarded.


     III.2 Aides and Citadel-86's net
        The Aides of a Citadel-86 system gain only one extra capability that a
     Normal User doesn't have, and this is called the Local Systems
     Announcement. This is the ability to send a Mail> item via the network to
     a user on all systems which are local to your system.  This is useful for
     informing all local sysops of an important development.

        An Aide does this by going to the Mail> room and using the .Enter
     Net-Message command.  When the system asks for a node name to send the
     Mail> to, the Aide should then answer with '&L'.  The Mail> that the Aide
     subsequently enters will then be sent to the user that they indicated on
     all local systems.

                                   -3-








     III.3 Sysop Capabilities
        Sysop capabilities in Citadel-86 regarding the network are numerous,
     and we will organize them into sections.  Note that Domain Management
     is in Section V, not in this Section (III).

     III.3.a Node Creation
        Before anything useful can take place on the network, you must have
     other systems (also known as nodes) to call. Therefore, we'll begin with
     adding systems to your netlist.  This netlist is called the "primary"
     nodelist (see Section V for information on what a "secondary" node list
     is.)  We add systems to a primary nodelist via the Network Menu, which is
     available to sysops from the Sysop menu as the 'N' option.  Once you have
     entered the Network Menu, type 'A' to add systems.  Your system should
     begin by asking for the name of the system to add, which you should type
     in.  Next it will ask for its Node Id.  It is important that you get this
     right.  The format of the node Id is

      <Country Code> <Area code> <Phone #>

        Country Code is the country code of your system's location, which
     should be listed in COUNTRY.MAN; US is the United States and CA is Canada.
     Area code is the area code of the system, and Phone # is the number used
     to call that system under normal circumstances.  Citadel-86 will usually
     use the node Id for calling other systems, which is why it's important to
     get this right. However, if you are in a special circumstance where using
     the node Id to call a system will simply not work (such as an intra-campus
     phone system), there are ways around the problem.  See Section III.3.c.

        An example of a valid node Id would be

     US [phone]

        Notice the use of punctuation.  Punctuation is stripped out of node
     Ids when dialing other systems, but punctuation should still be used
     conservatively.

        You will then be asked the baud rate of the new system.  Usually, you
     should answer with the highest baud rate that the new system supports; if
     your system doesn't support their highest speed, then your system will
     dial that system at the highest speed that your own system supports.
     Sometimes, though, you will have to answer this question with a lower baud
     rate, due to the fact that on some lines the network won't work at high
     speeds.  We are not entirely sure why, although we suspect that it's
     simply the phone system's fault.

        Finally, you'll be asked if the system is local or not.  This question
     also affects how your modem will dial this system during networking, and
     here's how:

        If you answer that this is a local node, then the modem will be dialed
     using

        <#callOutPrefix><phone#><#callOutSuffix>




                                   -4-






        (If you don't know what #callOutPrefix and #callOutSuffix are, please
     review the Citadel-86 Installation Manual, or see Section V of this
     manual.) Essentially, we just dial the system as a local call.  But if
     you answer that the system is not local, then the modem dials with

        <#callOutPrefix>1<area code><phone#><#callOutSuffix>

        This is just a normal LD call in the United States.  All of this can
     be overridden, as stated above: see Section III.3.b.i.

     III.3.b Node Administration & Member Nets
        Nothing stays the same, including nodes on your netlist.  Therefore,
     there is an editing ability for nodes.  You may access this via the
     Network Menu. Once at the Network Menu prompt, type 'E' for Edit Node.
     The system will ask for the name of the node to edit, so type the name of
     the node that you need.  Once you type a valid name, you will be given a
     short summary of that node's condition, and then a Node Edit prompt will
     show up.  From this prompt you may do the following:

      A - Override the dialing format described in III.3.b
      B - Change this system's baud rate
      C - Change the condensed name of the system
      D - Download Toggle for this system
      E - External Dialer access for this node
      F - Fast Transfers
      I - Change this system's Id
      K - Kill this system from the net list
      L - Change the Local setting
      M - Change which nets that this system is a member of
      N - Change this system's name
      O - OtherNet toggle
      P - Activate security measures for this node
      R - View which rooms you are sharing with this node
      S - Spine settings

        Let's take these one at a time.

     III.3.b.i Special Access Strings
        'A' from the Node Editing prompt lets you change the Access string for
     calling this node.  If you give this string any value, the procedure for
     calling this node will change to the following:

        <#callOutPrefix><access string><#callOutSuffix>

     which makes it very easy to construct special dialing sequences for nodes
     in special situations.  Use this with some caution.  If you want to
     use an external dialing program (for instance, to use PC Pursuit to
     call another node), see later in this section.

     III.3.b.ii Baud setting
        'B' allows you to reset the baud rate for this system.

     III.3.b.iii Condensed Names
        'C' allows you to change the "condensed" name of the system.  A
     'condensed' name is a name of your choosing of no more than 2 letters,
     which is nothing more than a useful shorthand for you.  You may use this
     shorthand in almost any situation in which you'd type the name of the
     system, such net mail, Dial out, etc.


                                   -5-






     III.3.b.iv Download Toggle
    'D' allows you to toggle the download flag for this system.  Ordinarily
     set to ON, if it's turned off then this system may NOT download files
     from your system during network sessions.

     III.3.b.v External Dialers
         Citadel-86 supports (V3.32), in a rudimentary way, external dialers.
     An external dialer is a program capable of using some method other than
     normal dialing to call another system. A well known example is PC Pursuit.

         To tell your installation that in order to reach some system on its
     primary nodelist it must use an external dialer, use the 'E' option while
     editing that node.  The system should then ask if you want to set up this
     node to be dialed via an external program.  If you answer Yes, the system
     will then prompt you for information on dialout.

         This "information" is system dependent.  For Citadel-86, the informa-
     tion should be the command line which will cause the external dialer to
     try to make connections with this node.  I'm sorry, but at this point
     you're on your own as to what goes in this string -- it'll depend on how
     the external dialer you have works, etc.  And, no, I'm not writing any
     external dialers for PC Pursuit, Starlink, etc., either, and I don't have
     any to distribute. Citadel-86 will simply send your command line to DOS
     for execution.

        The external dialer you use should leave the system with carrier high
     and ready to network (i.e., connection has been made with the system
     you want to talk to) if it succeeds, otherwise not have carrier.

        If anyone develops or otherwise finds an external dialer for Citadel-86
     or Citadel-68k which works well, a few sysops might be really really happy
     if you mention it in Sysop Stuff.

     III.3.b.vi Fast Transfers
    Citadel-86 can be configured to use one of the popular compression
     programs and Zmodem to transfer net messages (resulting in big savings,
     we think, of time) on a system by system basis.

     III.3.b.vi.1 Who is this appropriate for?
    Using this option is appropriate for systems connecting to LD systems
     for purposes of transferring large numbers of messages during one session
     per night or less.  Large numbers may mean as few as 30 or 40 messages.
     In reality, it depends more on the mass of messages -- i.e., how many
     bytes are being transferred either way a night.

    While there is no reason this option cannot be used for local
     networking, the benefits do not seem to be as clear.  There are also costs
     inherent in this scheme which may cause this scheme not to be appropriate
     for local netting.

    Systems wishing to use this scheme should not be using slow h/w, and
     should have a full complement of memory available since the compression
     programs are run while Citadel-86 is in memory (of course).

    If you have doubts about being able to run a compression program, use
     Outside Commands to experiment with both command lines (Compress and
     Decompress).

     III.3.b.vi.2 Administration
    First we'll deal with administrative issues.

    Once the appropriate version of Citadel-86 (& Ease, if you use Ease)
     has been obtained, these steps must be followed:

     1) [optional -- only if you have Zmodem configured into your system] Put
     on your Citadel command line the option "zmodem=<character>", where
     <character> is the character a user would select in order to use Zmodem
     to transfer a file or messages.  For most systems this will be 'z', so
     the command line would look like this:

    ctdl zmodem=z ...

     If you don't have Zmodem configured into your system, DON'T WORRY.
     Citadel-86 will happily use one of the internal protocols to transfer the
     message file, instead.  However, the internal protocols are not as fast
     as Zmodem, so ...

     2) Setting up Compression.  If you use Ease, this is easy.  Using Ease,
     simply go to the Misc Menu, select Compression utilities, and then select
     each compression utility you support and you'll find the menu in these
     windows contains a new entry line for Compressing FIles.  This is just
     like Decompression -- simply put in the command line needed to compress a
     file.

    Care should be taken when configuring the compression command lines
     since compression utilities often have incompatible versions (at least,
     old versions won't decompress files generated with new versions).

    I am not completely familiar with all of the utilities, but configuring
     those that you have set up for the Decompression is certainly a good idea
     (you'll find later you can select on a system by system basis which
     compression method to use).  The various Compression command lines I'm
     aware of (not all have been tested):

    lha u        (LHA/LHArc)
    arc u        (SEA ARC)
    pkzip -u     (PK's Zip)
    zoo -update  (Zoo)

    Citadel-86 will attempt compression by running a command composed of the
     compression command line followed by the name of the file to update or
     create with the compressed files followed by the wildcard "*.msg".

    If you don't use Ease, then you should know that the files in question
     are DEARC.SYS, DELZH.SYS, DEZIP.SYS, and DEZOO.SYS.  The Compression line
     is the third* line of the file (not the second).

     3) Also make sure you have Decompression command lines setup for those
     methods you'll support!!!!  Or you won't be able to receive Fast Transfers
     from other systems.

     4) Now bring your system up.  Go to the Net Menus, and select a system to
     edit that you think you'll be doing Fast Transfers with (or will be testing
     with, or whatever).  The option to turn on Fast Transfers is 'F'.  When
     you select it, it will be toggled on and you will be asked to select which
     Compression Method to use; only those that you configured will be
     displayed for your selection.  At this point you should know which method
     you plan to use with the other system (usually LHA, but make sure the
     other system is aware of the method you intend to use).

    If you want to turn Fast Transfers off, just select 'F' again.  If any
     messages happen to be 'cached', (see below) don't worry, they'll still be
     transferred, using the old message transfer methods.

     III.3.b.vi.3 What this does to your computer

     1) In your #NETAREA directory you'll find a new directory named NETCACHE.
     In it you'll find more directories with numerical names.  They will
     correspond to your node slots, and are only created when you select Fast
     Transfers for a given system.  I.e., don't be surprised to see huge gaps
     between numerical names, such 4 12, 44.  These directories are not deleted
     if Fast Transfers are turned off for any system (but may be when you
     delete a system if it had Fast Transfers on).  Don't worry about lack of
     deletion.

     2) In those subdirectories you'll find "cached" messages from time to time.
     A cached message file (either <number>.msg or V<number>.msg) contains most
     (or all) of the messages bound for the system represented by the directory
     for a single room.  A room with no messages outbound for the system will
     typically not have a file present.  You may also find a compressed file
     (named NETMSG.<something>), which should contain all of the *.MSG files
     in this directory.

     3) During networking for normal rooms ...

     a) If your system is doing the calling, first it will cache and compress
     all messages meant for the target system.

     b) If your system is receiving the call, caching and compression will take
     place during the network session.  Hopefully, this won't take too long. If
     you think it does and the incoming system(s) calls at a consistent time,
     see the #event described below.

    If you are using virtual rooms (so few of us are), virtual rooms are
     cached to all systems sharing them upon receipt of the virtual room.  The
     reason this is not done with normal rooms is to keep us from caching
     messages later deleted by our Aides.  It would be a code nightmare to
     decide we need to recache* some messages just because a message was
     deleted, so we simply delay caching until we need to transfer the messages
     (or at least think we'll need to transfer them).

     III.3.b.vi.4 Error Handling
    If someone is not configured for Fast Transfers when you are, don't*
     panic.  No messages should have been lost; instead, Citadel-86 simply
     grabs the cache files and sends them as a normal shared room.

    However, if for some reason the decompression is not working correctly,
     or Zmodem isn't working, stuff could get screwed up.  A little cautious
     testing beforehand, if you can manage it (say, with a local system you
     don't share much with at the moment, or a spare computer of your own),
     won't hurt at all.

     III.3.b.vi.5 Related #events
    See below in the special section on network #events.

     III.3.b.vi.6 Peculiarities

    1) Mail is NEVER sent this way, either direct or route mail.

    2) Shared rooms whose names are 0 length (a rare but not unknown bird)
     are not shared in this manner; they are sent by themselves as a normal
     shared room.

    3) If you are calling out, Fast Transfers will not occur unless the
     other system is local or you are setup to be a spine for that system.

    4) If your system is calling another LD system but has no outgoing
     messages in any room, Fast Transfers will not occur from your side, but
     will from the other.  Don't panic if you see that happen.

     III.3.b.vii New Node ID
        'I' allows you to change the Node Id of this system.  When you use this
     option, you will be asked if you are changing the meaning of this node
     entirely, that is, you are making this record refer to another system
     entirely. This is for the purpose of Mail forwarding and room sharing,
     so answer this correctly.

     III.3.b.viii Kill System
        'K' causes this system to be deleted from your node list.

     III.3.b.ix Change Local/LD setting
        'L' lets you change the Local/LD setting for this node.

     III.3.b.x Change Name
        'N' allows you to change the name of this node.

     III.3.b.xi Network Passwords
        'P' allows you to setup security arrangements between this node and
     yourself.  Security arrangements consist of two passwords, one of which
     applies to your system, while the other applies to the node that you are
     editing.  If neither your system nor the node that you are editing are
     using passwords, then security is not active.  If either system is using
     them, then security is active, and passwords must match during networking
     in order for room sharing to be successful.


                                   -6-






     III.3.b.xii Room List
        'R' allows you to see a list of the rooms that you are currently
     sharing with this node.

     III.3.b.xiii Member Nets
        'M' allows you to change the nets that this system is associated with.
     Citadel-86 allows you to associate any node on your node list with 0 or
     more nets, up to 31.  When a node is created, it is automatically
     associates with net 1 as a matter of convenience.

        The utility to assign a node to different nets is that, in conjunction
     with the #event parameter (covered in Section III.3.k), you may then
     network with different nodes at different times and/or days. This gives
     you a lot of flexibility to participate in different nets at different
     times. If necessary, you can assign a node to more than 1 network.

        If you take a node off of all the nets, then the node is disabled,
     which means that Mail> cannot be sent to that node.

     III.3.b.xiv Spine Settings
        'S' lets you set the Spine settings.  The meaning of Spine in C86Net
     depends on whether the system is LD or not.

        First, LD systems.  Normally, a C86Net node, when calling a local
     system, will after transferring data to the receiving node, will perform
     a 'role reversal' with the other system, which allows the receiver to
     transfer messages to the caller, thus saving time during networking.
     However, due to the existence of Long Distance charges, role reversal is
     not performed on Long Distance calls.  The Spine settings lets you
     override this behavior.  When you elect to use the 'S' command while
     editing a node, the system will first ask if you wish to be a Spine for
     the system you are editing.  If you answer Yes, Citadel-86 will perform
     role reversal with this system during calls.  If you answer No, then the
     Citadel-86 will ask if that system will be a Spine for you, and if you
     answer Yes, then your system will never call that LD system again,
     instead relying on it to role reversal during calls.

        If the system you will be dealing with is local to you, and you set it
     as a spine (or yourself), then the system designated as a spine is
     guaranteed to try for one successful network call during each network
     session, even if the caller has no valid reason for calling.  This allows
     the existence of systems with bad modems in the network.

        There is an alternative, perhaps better, method for editing nodes.
     See Appendix D for details.  This is important, since the above does
     NOT cover all flags associated with nodes, but the option covered in
     Appendix D does.

     III.3.c User Administration
        For any user to use the room sharing or net Mail> abilities, they must
     have "Network privileges".  There are two ways that Network privileges are
     assigned. The first is via the CTDLCNFG.SYS parameter #NewNetPrivs, which
     allows you to decide whether or not new users automatically have net
     privileges (see Section V).  The second method is via the Network menu.
     The Network Menu is available to sysops from the Sysop menu as the 'N'
     option.  Once you have entered the Network Menu, type 'N' to set Network
     privileges and follow the prompts.  (The same capability also exists in
     the User Admin sysop menu.)

                                   -7-






        If you (or other users) wish to send Mail> via the net to LD systems,
     then you must assign one or more LD credits to the appropriate accounts.
     You do this from the Network Menu as well.  Type 'C' at the Network Menu
     prompt and follow the prompts.  Each Mail> message to a LD system costs
     exactly one credit; there is no accounting on a byte count basis.

     III.3.d Normal Shared rooms
        Sysops have the ability and responsibility of administering shared
     rooms; this section covers normal shared rooms.

        A shared room, as noted above, is a room which will send to and receive
     from other systems certain messages which were entered in the room.
     Normal shared rooms transmit their messages using the point-to-point model
     of networking.  For each system that you are sharing this room with, your
     system will call that system and send only the net-messages that were
     originally entered on this system.  There is no routing for normal shared
     rooms.  If you have a pressing need for routed rooms, see Section III.3.i.

        To make a shared room, go to (or create) the room that you wish to make
     a shared room, and edit the room.  At the room editing prompt you should
     type 'S', which is the command for Shared rooms.  The system should now
     ask if you want to make the room a shared room, so answer 'Y'.  Now you
     will be asked to enter the systems that you wish to share this room with.
     If the room was already a shared room, then you do NOT have to re-enter
     any systems that you are already sharing this room with, but only the
     systems which were not sharing the room before.

        Once you have finished entering the systems to share this room with
     you will be asked to enter the names of the systems to remove from room
     sharing.  Answer appropriately.

        Finally, you will be asked if you want this room to be an autonet room.
     If you answer 'Y', then the system will ask if only people with net
     privileges will have their messages automatically made into net messages,
     or if everyone will have this privilege.  If you answer that only
     people with net privileges will have the ability, then only they can
     enter net messages in the room, and all other messages will be normal.
     If you answer that everyone's messages should be converted, then that's
     what will happen, regardless of their privilege setting.

        In order to have a successful shared room, all systems with which you
     wish to share this room with must have a room with an identical name, and
     must know that you want to share this room.  There is no such thing as
     involuntary sharing of rooms.

     III.3.e File Requests
        Sysops have the ability to request file(s) from other systems.  In
     order to do this, you must know the name of the room and the name of the
     file(s) that you wish from the other system.

        You may access this facility from the Net Menu by pressing 'R'.  You
     are then asked for the system's name, the name of the room on the system
     that has the file(s) that you want, and the name of the file(s).  You may
     specify an ambiguous name for files, but your specification must be one
     that the target system understands, rather than what your system
     understands, so this may vary.



                                   -8-






        You will then be asked for a location to place the files when your
     system receives them.  You may specify anywhere on your disk system, but
     you should try to ensure that you have enough room for the files.

        As a Citadel-86, your own directory rooms can be accessed via the
     network for file transfer unless you otherwise designate.   To do so, go
     to the room that you wish to be impervious to the net, edit the room, and
     type Z, which will give the option of disabling this room for net
     downloading.

     III.3.f Sending Files
        Sysops have the ability to send file(s) to other systems.  There are
     two aspects to this ability.

        First, sending a file.  This facility is accessed via the Net Menu by
     pressing 'S'.  You will be asked for the name of the system to send the
     files to, and the name of the files to send.  You may specify any location
     on your system for the files, and your specification may be ambiguous, so
     that you send multiple files to the target system.

        Second, receiving files.  You can control how much space you wish to
     devote to files that are sent to you via the net and the maximum size of
     any file you receive, as well as the location for the files to end up at,
     through parameters in CTDLCNFG.SYS.  Please review The Citadel-86
     Installation Manual or read Section V for more details on this.

     III.3.g Priority Net Mail
    The Sysop may specify one or more system should be called immediately,
     regardless of their status, for the purpose of delivery of Mail by the use
     of the 'P'riority Mail option on the Network menu.  This is a precise
     statement; only mail will be delivered (domain and direct), no rooms will
     be shared, no files sent, and most importantly nothing will be received
     from the system(s) called.

    The Sysop may specify any system on their primary net list, even if
     the system is disabled (not on any Member nets) or is not on a member net
     on a currently active anytime net session.

    When the Sysop logs off (or the system is put back into Modem mode)
     the system will immediately lapse into a network session.  One, and only
     one, attempt will be made to contact each system designated for Priority
     Mail.  Regardless of success or failure no more attempts will be made
     unless the Sysop once again assigns the Priority Mail.

    The inquisitive sysop will notice systems assigned to Priority Mail
     will temporarily be assigned to Member Net 32.

     III.3.h Until Net Sessions
    System Operators may ask their system to execute a net session with
     some set of systems by using the 'U'ntil Done Net Session option.  This
     option, which is very closely related to the 'until-done-net' class of
     events (see INSTALL3.MAN or further below in this manual), gives the
     system operator the ability to indirectly designate one or more systems
     to be called as soon as the system is no longer in use.





                                   -9-






    When the System Operator selects this option, they will be prompted
     for a 'Member Net', rather than a system name.  The answer should be
     a number between 1 and 31, inclusive, which is then taken to be the
     Member Net to use for finding eligible systems to call.  Eligible systems,
     then, are of course those systems which are assigned to that Member Net.
     A second question requests how long this network session should last
     while attempts are made to contact all systems requiring contact.

    The recommended procedure when using this option is to first place
     the system(s) you wish to contact onto some Member Net which is not
     normally in use (see above for the procedure to assign Member Nets).
     When all systems are so assigned, then select this option.  Please
     keep in mind that, unlike the #event, you may specify only one Member
     Net.

    If you wish to poll a system, even though there is no reason to call
     the system, edit the desired node, select 'S'pine to make your system
     a spine for that system, and then follow procedure to execute an Until
     Done Net Session.  Once the session is complete, you should probably
     re-edit the given node so that you are not a spine for that system --
     unless, of course, you intend to remain a spine for that system.

    If you wish to delete a session you just scheduled, simply go through
     the same routine.  When you specify which Member Net, the system should
     detect the impending duplication and will delete the session, instead.

     III.3.i Miscellaneous Net Menu Options
        There are a couple of Net Menu options that haven't been covered yet.
     They are:

        'V'iew the net list.  This option lets you view all the systems on your
     netlist.  The format is

     <name>  <nodeId>   <need to call>  <baud> <disabled flag>

        "need to call" and "disabled flag" only appear if they are true.

        'D'ial out allows you to dial other systems manually for BBSing
     purposes. After causing your modem to dial that number, the system will
     drop you into chat mode.  You can dial systems that are disabled, thus
     allowing you to list systems which are not C86Net compatible.

        'L'ocal list lets you list all systems on your primary node list
     which are marked as "local".

        'I'nitiate Net session lets you schedule an anytime net session to
     begin as soon as you log off.  While this is not as convenient as just
     typing "^A" while the system is in MODEM mode, it's useful when you
     are calling in from remote and want to trigger a net session as soon
     as you logoff.  This is a toggle switch; hit it again to turn off the
     net session you just scheduled.

     III.3.j Advanced Room Sharing Options: Routing
        C86Net (and thus Citadel-86) has support for Room Sharing routing.
     This is an advanced option, and should be approached with caution.




                                   -10-






        Routing in C86Net is used to transfer messages from one group of one
     or more systems to another group of one or more systems.  Commonly, this
     is between two different toll areas in order to reduce costs while
     maintaining communications; however, there is no reason that with careful
     planning routing cannot be used within a toll area.

        Normal room sharing and room sharing routing can be, and usually are,
     used together.  Graphically:

      R1         |  R2
         p1
         | \     |
         |  p3- - - -p4
         | /     |     \
         p2             p5
                 |

        In this diagram, p1, p2, and p3 communicate with each other using the
     Normal room sharing facility, as does p4 with p5.  However, p3 and p4
     communicate using the routing facility; p5 then communicates with p1, p2,
     and p3 indirectly via p4 (and vice versa, of course).  This is a simple
     situation; complex situations can also be handled:

      R1         |  R2       | R3   |  R5
         p1                                    p11
         | \     |           |      |         /
         |  p3- - - -p4- - - - -p6- - - - -p10
         | /     |     \     |  |   |         \
         p2             p5      |              p12
                 |           |--|---|
                        /----   |   ----\
                       /    R4  |        \
                      /         p7        \
                     /         /  \        \
                    /        p8    p9       \

        p6, for instance, only performs routing, while p3, p4, p7, and p10 will
     perform both normal and routing.

        So how do we explain this in a coherent manner?  First, let's remember
     that all of this applies on a room by room basis; a system that is
     performing routing for one room may be performing normal room sharing for
     another room.  Now let's define some classes of nodes.  The first class,
     PEONs, encompass the majority of nodes sharing any room, since most nodes
     do not need to route messages.  The second class of nodes, BACKBONES, are
     capable of routing.

        PEON: This is a node that thinks it is participating in a normal
     shared room.  A PEON node never "knows" that the room is being routed by
     another node, and so the administration of this room is very easy for PEON
     nodes.  This is because the node(s) that may be performing the routing
     role for this room always talks to PEON nodes using the normal room
     sharing schemes.

        Let's formalize the rules of PEON room sharing (this is just a review
     of Section III.3.f).  A PEON node regards the room being shared as part of
     a point-to-point network, and therefore always calls all systems that it


                                   -11-






     is directly sharing the room with whenever it has new net-messages that
     were entered on this PEON node to send.  Incoming net-messages are never
     passed on to anyone else.  Systems that are compatible with C86Net but
     don't support the advance room sharing routing schemes should be easily
     able to participate as a PEON node in a room that is being routed by
     someone else.

        BACKBONES: A BACKBONE for a room is a node which is capable of routing
     messages from one node to one or more other nodes.  Let's set down the
     rules of routing as precisely as possible for BACKBONEs.

     a) Each node a system is directly sharing a given room with will be either
        a PEON (explained above) or another BACKBONE, and the system will know
        (be told by the sysop) which each node is.  The type of node (PEON or
        BACKBONE) determines which messages will be routed to that node during
        a network session, and will be detailed in b) and c), below.

     b) When the system shares a room with a PEON node, a BACKBONE assumes that
        the given system directly shares this room with all other PEONs which
        are sharing this room with this BACKBONE.  Therefore, the BACKBONE will
        not pass any messages from any PEON to any other PEON node.  From the
        narrow perspective of a collection of PEON nodes, a BACKBONE behaves
        exactly the same way, in fact those PEON nodes do not need to "know"
        about the BACKBONE status of the routing system, since it isn't routing
        messages from any of the PEON nodes to any of the other PEON nodes.

        When sharing a room with a PEON, a BACKBONE also assumes that the PEON
        has neither direct or indirect contact with any other BACKBONE systems
        besides itself except through* itself.  Therefore, a BACKBONE will pass
        on all messages received from any and all BACKBONE systems to all PEON
        systems connected with this room.

     c) When a BACKBONE system shares a room with another BACKBONE system, it
        assumes that, first, it does not have any communication with the PEON
        systems sharing this room directly with you (do not confuse this with
        any and all PEON nodes in its area, though), and secondly it does not
        communicate with any of the other BACKBONES which you communicate with.

        Therefore, when a BACKBONE is sharing a room with another BACKBONE, it
        routes all messages from all PEONs and all BACKBONEs to the BACKBONE
        it is sharing with.  This routes messages from local PEONs as well as
        allowing a series of BACKBONES to route messages to far-flung areas.

        A diagram is undoubtedly in order at this point.  This portrays the
     the sharing of a single room.


        P1-----                                          P10
       /|      \                                        /       Px= PEON x
      | P2------B1-------B2-------B4---------B5-------B6        Bx= BACKBONE x
       \|       /\               /  \         \         \
        P3-----/  \             P6---P7        \    P8   P11
                   B3                           \  / |
                  /  \                           B7  |
                 P4---P5                           \ |
                                                    P9



                                   -12-






        In the above diagram, any message left on any system in the given room
     will be seen on all systems in the diagram (eventually).  Let's follow
     the progress of a message from P1, Peon 1.  The message will reach P2 and
     P3 via direct room sharing (Section III.3.f),as well as B1 [see b) above].
     Since the message comes from a PEON, by the rules set forth in c) above
     the message from P1 will be passed on to both B2 and B3 when we come into
     contact with them.

        P4 and P5 will receive the message of P1 from B3 due to b) above, to
     wit: "... a BACKBONE will pass on all messages received from any and all
     BACKBONE systems to all PEON[s] ..."

        B4 will receive the message originating on P1 from B2, as noted in c)
     above, and in like manner will pass it on to B5, and also to P6 and P7
     as B3 did for P4 and P5.  B5 will pass on P1's message to B6 and B7, and
     they in turn will pass them on to P10 and P11, P9 and P10, respectively.

        There are two types of BACKBONEs, differentiated by their calling
     characteristics.  This is a bit of sticky point: a system may be both
     types of BACKBONE for any room as required (and in practice many are
     both).  Essentially, the type of BACKBONE a system is for a room defines
     the system's relationship with another node.

        When a system, for some room, is defined as a PASSIVE BACKBONE for some
     node, this means that this system will not call the other system during
     net sessions when the only reason to call would be to share this room.
     PASSIVE means "do nothing", and that's what a PASSIVE BACKBONE does: it
     waits for the other node to call.

        And, conversely, when for some room a system defines itself as an
     ACTIVE BACKBONE for some other node, it is guaranteeing that it will call
     (or poll) that node for messages once during a net session, no matter if
     it has new messages to share or not.

        Why would a system want to be both ACTIVE and PASSIVE for a single
     room?  Suppose we had this:

       B1------B2-------B3------B4

        By allowing a system to assume either PASSIVE or ACTIVE roles, depend-
     ing on the system in question, we can for instance allow B2 to be ACTIVE
     in relation to B1, while PASSIVE in relation to B3.  This allows the costs
     of netting to be more evenly spread.  Then B3, itself ACTIVE in relation
     to B2, can be PASSIVE in relation to B4.  In this way, no one carries the
     costs of calling two backbones (and B1 gets off scot-free!).

        The type of BACKBONE a system is does not affect what messages will be
     routed.  For instance, messages from B1 will reach B4, and those of B4
     will reach B1.

        So, now you're wondering how to actually get these setup, right?  This
     is accomplished by editing the room.  First, use 'S' to enter all systems
     sharing this room DIRECTLY with, including all of your local PEON nodes,
     and all the BACKBONES that you will be talking to, but NOT any non-local
     PEON nodes (i.e., PEONS that will receive your region's messages via
     routing). After finishing that, hit 'B' at the Room Edit prompt.



                                   -13-






        You will then be asked three questions: which nodes do you want to be
     PASSIVE BACKBONES for, which nodes you wish to be ACTIVE BACKBONES for,
     and which nodes you wish to return to PEON status.

        Here are three last thoughts on routing.  First, you may wish to
     consider using the Member nets to separate nodes into two different
     classes, and then network at different times for the different classes.
     For instance, in the Twin Cities we network from 3 to 3:45 in the morning
     for local room sharing.  At 3:45 all but one of the systems returns to
     normal operating mode.  That remaining system drops from the first
     networking session, which was for net 1, and then goes right into another
     network session again, but this time for net 2, which keeps it from
     trying to talk to anyone else but for a system in New York, which
     functions as an ACTIVE BACKBONE for several rooms (the lone system in the
     Twin Cities functions as a PASSIVE BACKBONE). This networking session
     lasts for 15 minutes, which is normally more than enough time to complete
     this single call. Therefore, we usually have a successful nightly
     connection with New York.

         Our second thought relates to network configurations and routing.  So
     far, all of our diagrams have had two BACKBONES (or at least a HOST and a
     BACKBONE) communicating.  While this is normal, it is also possible to
     have a configuration like this when all nodes are local to each other:

               p1
               | \                   p1 = p3 = p4 = PEON
               |  B2 - - - - p4      B2 = ACTIVE BACKBONE for p4
               | /
               p3

        When all the nodes are local, B2 will communicate with p4 using the
     normal room sharing protocol rather than using the routing protocol.
     This is useful when p4 has C86Net compatible software that does not
     support routing, along with a modem that will not dial out.  If p4 were
     to have software that supported room sharing routing, but still had the
     bad modem, then p4 could of course be classified (classify itself) as a
     HOST or PASSIVE BACKBONE for B2. Since an ACTIVE BACKBONE always calls
     other BACKBONES, in either case then B2 should make at least one call to
     p4 for pickup and delivery.  If p1 and p3 simply had p4 classified as a
     PEON node, then there is no guarantee that p4 would receive nightly calls
     from all systems.

        Third and finally, it is not always necessary that one BACKBONE know
     that another system is a BACKBONE.  For instance,


                  /----P1-----\
     . . . -----B1------|------B2----- . . .
                  \____P2_____/


     is thoroughly valid if both B1 and B2 think of each other as PEONs, even
     if they act as BACKBONEs.  The PEONs would, of course, treat B1 and B2
     as fellow PEONs, not knowing any better.  Since B1 thinks of B2 as a PEON,
     it would not route any of the messages from P1 and P2 to it (and B2 would
     get those messages directly), but it would route messages from other
     BACKBONEs to B2 as well as P1 and P2.  B2 would accept all messages from


                                   -14-






     B1 as PEON messages and thus not route them to P1 and P2, but it would
     route them to BACKBONEs connected to B2.  This might prove useful in some
     situations.

        Confusing?  For us, too.

     III.3.k Advanced Room Sharing Options: Virtual Rooms
        Let's begin with motivation: A certain PASSIVE BACKBONE discovered
     that while a certain room that he was backboning certainly belonged on
     the network, he didn't want that particular room on his system, because
     it didn't fit the atmosphere of the system.  Furthermore, the traffic
     in that room was so heavy that it was scrolling his message base faster
     than he liked (due to the fact that the messages in shared rooms are
     stored in the message base, just like any other message).

        Thus, the need for 'Virtual rooms' was discovered.  A Virtual room,
     much like Virtual memory, is a room that isn't really there, even though
     you route messages.  Messages, rather than being stored in your message
     base, are stored as files on your disk system, not taking up room
     in your message base, although they do consume room on your disk system.
     So, you have the ability to perform routing services for other systems,
     while not cluttering your message base with them.

        Virtual Rooms administration is completely contained in the
     utility VIRTADMN.EXE, which cannot be run through Citadel-86's
     <O>utside Commands menu; you must take Citadel-86 down in order to
     run VIRTADMN.  VIRTADMN should be fairly self-explanatory for the
     experienced sysop when used in interactive mode.  The following
     structure is created and maintained by VIRTADMN:

                        <C-86's home level>
                                |
                             VIRTUAL    <ctdlvrm.sys, ctdlvnet.sys>
                                |
                        ------------------
                        |   |   |   |   |
                        0   1  .......  N
                                        |
                                       --------
                                       |      |
                                     PEON  BACKBONE

        The numbered directories within the VIRTUAL directory correspond
     to the virtual room slot numbers; since Virtual Rooms can be deleted,
     this sequence can be broken.  Each of these directories contain the
     pair of directories PEON and BACKBONE.  The PEON directory contains
     the messages from PEON nodes, which should be routed to Backbone
     systems, while the BACKBONE directory contains messages from Backbone
     systems that need to be routed to other Backbones and Peons.  Like
     normal backboning (III.3.i), your system may serve as a Passive Backbone
     for some systems and Active Backbone for other systems for any given
     room.







                                   -15-






        Naturally, as the network sessions pass, you will find that the
     files containing the messages will accumulate, cluttering up your disk
     drive.  The solution is to run VIRTADMN using the +batch command line
     argument.

        See UTIL3.MAN for full details on VIRTADMN.

     III.3.l Advanced Room Sharing Options: Vortex Detection and Correction
        "Vortex" is a piece of jargon someone on C86Net came up with to
     describe the phenomenon of messages 'repeating' themselves in shared
     rooms.  For instance, a message from Thom Brown might reappear three times
     in a shared room on Test System.  The redundancy is both tedious and room
     consuming, and so is a negative influence on the network.

        A vortex is usually a result of poor topology management of a C86Net.
     If you are not familiar with C86Net backbones and other such things,
     please read III.3.i Advanced Room Sharing Options: Routing.  The problem
     lies in having a "loop" of systems, usually BACKBONE systems.  For
     instance, this configuration would cause a vortex:

                     Node A
                    /   |         Where all nodes are backbones
                 Node--Node
                   B    C

     Messages generated on Node A would be sent to Node B.  Node B would then
     pass them on to Node C, which in turn would pass them right on back to
     Node A.  If those backbones had other backbones hanging off of them,
     messages coming in from those would effectively "bounce back" to them.
     There are obviously a number of variants on this mistake that can cause a
     vortex.

        Another cause of vortexing is system crashes during networking, such as
     power outages, in which messages will be sent by one system to another,
     but that fact is never recorded, thus causing them to be resent during the
     next network session.

        So how does Citadel-86 handle vortices?  Any message on the network can
     be uniquely identified by its point of origin (node ID) and the message
     number it was assigned on the point of origin.  Both data are carried by
     the message wherever it goes.  We also assume that message numbers are
     assigned in strictly ascending order.

        Therefore, the way to handle vortices is not very complex.  For each
     system which we share rooms with, either directly or indirectly (that is,
     via routing), we keep a file of room indicators and associated message
     numbers and dates.  For each room in this file, the associated message
     number is the number of the highest message received from this node for
     this room, and the date is the date of the last message received.  Once
     an entry is established for a room in the node's file, it's a simple
     matter to detect vortexing messages: if the current message comes from a
     node which we recognize, we simply compare the current message's number to
     the highest we have received for this room, and the date similarly.  If
     both tests are failed, we discard it.





                                   -16-






        Messages which are discarded will also cause an error message to pop up
     in the Aide> room, telling you what system was involved in the net session
     when the vortex occurred, and what systems' messages were involved in the
     vortexing.  The message(s) discarded may possibly also show up in a file
     named DISCARD.

        The records of the systems are kept in two files, VORTEX.SYS and
     VTXIND.SYS, in your #NETAREA; they are not related in anyway to
     CtdlNet.Sys.  The records of the rooms they appear in are kept in the
     #.VEX files, where '#' corresponds to the systems' positions in
     VORTEX.SYS, again in #NETAREA.

        Occasionally, vortex records are corrupted, which you will notice
     because messages are being rejected when they shouldn't be.  You fix this
     using the following procedure.  Use the utility VEXFIND.EXE to find the
     number of the system within VORTEX.SYS by typing

         VEXFIND "<system name>"

        You must use the "formal" name of the system.  For instance,

         VEXFIND "test system"

     will NOT work.  Instead,

         VEXFIND "c-86 test system"

     will yield the number of Test System.  Running VEXFIND without anything
     on the command line will get you a list of systems in VORTEX.SYS.  You
     may run VEXFIND in either of two places: in the same place you run
     Citadel-86 from, in which case Citadel-86 will use your CtdlTabl.Sys to
     find the vortex records, or in your #NETAREA, where Citadel-86 will find
     the vortex records without help, and will be a bit faster, too.

       Once you know the number of the system within VORTEX.SYS, you should
     delete the corresponding .VEX file.  For instance, if you found Nowhere
     was in position 34 of your VORTEX.SYS, you would delete 34.VEX.

        By default, vortex management is off.  If you wish to have vortex
     detection and correction active, place "+vortex" on your command line.
     There are several reasons why you might not wish to have it active, such
     as not enough disk space, not worth the time, etc.

        Citadel-86 Vortex handling does not cover Virtual Rooms.  All such
     messages are regarded as non-vortexed.

     IV. Networking and events
    Naturally, a new System Operator will want to know: how does one
     initiate network sessions?  What are the entries to make, the guidelines
     to follow?  There are a varieties of options of several types which all
     interact to make your life joyfully miserable.

     IV.1 Member Nets
    All of the event classes described here depend upon the concept of a
     "member net" (see above on how to assign a system to a member net).  For
     those who have not run across this explanation before, a Member Net (a
     number between 1 and 31, inclusive) is a way to group zero or more


                                   -17-






     systems together for purposes of using that group in a network session or
     something network-related.  Your system can have 31 such groups, each
     having zero or more systems assigned to it, and each system on your
     primary nodelist may be assigned to zero or more of those nets.

    This ability gives you the flexibility to place certain systems sharing
     some characteristic (such as being local to you) in one group and then
     using that group in one or more events for some purpose, while not
     involving systems not sharing that characteristic in the given event.

     IV.2 Normal Network Sessions
    A "Normal Network Session" is a scheduled network session in which
     your system drops into network mode at a specified time, stays in it
     until a specified amount of time has passed, and may call other systems
     during that time (depending on what systems are assigned to the Member
     Net(s) assigned to an event of this type).

        Network sessions are set up using the #event parameter of CTDLCNFG.SYS,
     and look as follows (please review The Citadel-86 Installation Manual if
     you are not familiar with the general format of #event parameters).

     #event <days> <start time> network preempt <duration> <message> <networks>

        Days, start time, and message are explained in the Installation Manual.
     While the network field is required, preempt is only a suggested field
     for this #event, on the assumption that you do not wish users to interfere
     with your netting (not using preempt can result in shortened duration of
     network session, also).  Duration defines how long the network session is
     to last (specify in minutes).  Finally, "networks" is a list of nets who's
     members are eligible to be called during this network session.  If you
     specify more than one, you must separate them by commas, with no spaces.

    Using #event for networking is straightforward and easy to do.  Here
     are some rules to follow

        a) Classify nodes that you want to network with into groups that
           share characteristics that will reflect on what time of the day
           (or day of the week) you may want to network with them, and assign
           them to the same net.
        b) Coordinate with them suitable times for network activity.
        c) Write appropriate #event parameters for your system that will
           allow netting with the systems.

        Here is an example for networking every night at 3AM for 45 minutes for
     systems on net 1.

     #event All 3:00 network preempt 45 "Networking" 1

        This is an example for netting from 4:45 to 4:55 on Tuesdays and
     Saturdays for nets 3, 9, and 10.

     #event Tue,Sat 4:45 network preempt 10 "Networking" 3,9,10

     IV.3 Anytime Network Sessions
        Citadel-86 also allows "anytime netting."  Anytime netting is the
     ability to receive and complete network calls from other systems at any
     time of the day or night, and to call, initiate, and complete network


                                   -18-






     sessions with other systems after a given amount of "dead time" has
     occured on a system.

        In the area of reception, an installation using the network will
     (or should) always recognize a network call from another C86Net system,
     regardless of whether the other system is calling out in Normal Network
     Session mode or in Anytime Netting mode.  There is currently no way to
     deactivate (i.e., force Citadel-86 not to recognize a network call) for
     specified parts of the day.

        In the area of calling out, Citadel-86 Sysops control this ability
     via the use of #events.  A Citadel-86 will not call out during the day for
     anytime netting unless they are specifically told to do so via the #event.
     The generic format of a #event that controls anytime netting is:

     #event <days> <start time> anytime-net quiet <duration> <message>
                                <dead time> <net length> <nets>

        (all on one line)

        This format is similar to that used for Normal Network Sessions.

     There are five changes.

        First, "anytime-net" specifies that for the #event starting at
     "start time" and ending at "start time + duration", the system is
     allowed to call those systems specified by the "nets" field.

        Second, "quiet" is the only valid type specification for events
     of the "anytime-net" classification.

        Third, "duration" does not specify how long the net session will
     last, but instead specifies how long the system is eligible to make
     calls to other systems.

        Fourth, a field named "dead time" has been included right after the
     "message" string.  You use this field to specify (in minutes) how long
     your system should experience inactivity before attempting to call other

     systems (specified in the "nets" field).  You might want to set this
     fairly high during daytime hours, if they are busy, so that your users
     have a better chance of getting on during the day, but set it lower
     during the night time hours, which might be less busy.

        Fifth, a field named "net length" has been added right after the "dead
     time" field.  This field specifies (in minutes) the maximum amount of
     time your system should spend trying to call other systems during an
     anytime net session.  This is much like the "duration" field in a normal
     network event, because a net session might last much longer for such
     things as large file transfers, etc.

        Anytime netting is compatible between just about any two systems on
     C86Net.

        Due to the above, you should group all of the systems that can accept
     anytime net calls into one net (and that you are willing to call at any
     time of the day), and then specify only that net for the #event parameter.


                                   -19-






        Odd thoughts:

        o If there is no need to call anyone, the system will not enter into
          net sessions after dead time limits are reached.
        o If you are a spine for another system, you will not call that system
          during anytime netting unless you have a "real" reason to call that
          system.  If you absolutely must* poll another system on a daily (or
          weekly, or whatever) basis, you must use a Normal Network Session or
          Until Done network session to do so.
        o During Normal Network Sessions, you may have noticed, there may
          be delays between calls of up to 5 minutes.  This has been disabled
          for anytime netting, resulting in only 2 second delays between calls.

        Finally, ^A while the system is in MODEM mode will tell the system to
     attempt to execute an Anytime Net session at the next opportunity (i.e.,
     when the current user, if any, logs off).

     IV.4 Until Done Network sessions
    An "until-done-net" class of event is very similar to a Normal Network
     Session (see IV.2), and uses the exact same format of parameter as a
     Network session, except the class is 'until-done-net' instead of
     'network'. The difference between 'network' and this class of networking
     session lies in its behavior.  If, during the network session, your system
     realizes that it has made all the calls it needed to make (as derived from
     the Member Nets in the parameter), it'll immediately drop out of network
     mode.

    Since this class of network session will call any spines which happen
     to be assigned to the Member Net assigned to this event, this event is
     useful to "force" a poll to a given system at a given time even if there
     is no reason for your system to call otherwise.  Once the network session
     is done, your system should once again become available to users.

     IV.5 Network Caching
    Network caching is related to the Fast Transfers feature mentioned
     in the Node Editing part of this manual.  In connection with this feature,
     a #event for caching all the messages for a given system has been
     implemented.  It is known as the 'netcache' #event.  The format is

    #event <days> <time> netcache <type> 0 "<whatever>" <nets>

     When this event is run by Citadel-86 it will cause all systems using the
     nets defined in the <nets> field (just like the normal network events) to
     have all messages meant for those system cached, rather than just the
     virtual rooms.

    Of course, if you are calling out for those systems, then this is
     rather useless, because the complete cache will take place before the
     outgoing call takes place.  However, if you have one or more incoming
     callers that use Fast Transfers, call at a consistent time, and you want
     to minimize call duration as much as possible (even though it seems like
     the phone system only measures calls in minutes, not seconds), you can use
     this #event to cache messages shortly before a network session may be
     expected to take place.

    Don't schedule this to take place during a scheduled network session;
     have it take place shortly before.

    This class of event should never be of type 'quiet'; 'preempt' or
     'non-preempt' is more appropriate (and up to you).

     V. Domains in Citadel-86

     V.1 What are domains?
        Domains are a way to partition a collection of BBS nodes into discrete
     sets for purposes of both easing user addressing and internal delivery
     details.  A solid real world example of domains is the US Postal Service.
     The primary domain is hierarchical.  The top of the hierarchy is encoded
     in their "zip codes".  The zip codes are used to quickly discover which
     geographical area of the country a given piece of Mail is meant for and
     the mail is then physically delivered to that area, or more accurately to
     a "server", or large Post Office, for that area.

        Once in the appropriate area of the United States, the next level of
     hierarchy is the street address (which is being replaced by the 9-digit
     zip codes).  There is redundancy at this level when the envelope bears the
     name of the city of the recipient.

        Another example is the phone system, where area codes are the domains.
     Everybody's phone is the member of one and only one domain.

        In a BBS network there is not a necessarily readily apparent method for
     dividing the nodes into domains; it is up to the nodes on the network to
     agree to an acceptable network division, based on whatever criteria seems
     best fitted to the situation.  (If you are on main C86Net, you'll notice


                                   -20-






     some pressure being exerted for systems to be parts of domains based on
     their physical location.  For instance, systems in Minnesota will, for
     the most part, belong to domain "MN".)

        Each domain on the network will then have at least one "server" system
     associated with it.  Most Mail meant for a system in that domain
     originating in another domain will go through the server for that domain.
     Some Mail won't due to special arrangements between systems.  For the
     purposes of this document we can ignore those special cases.

     V.2 So how does Citadel-86 utilize Domains?

        Citadel-86 utilizes domains in three important ways.

        First, it uses them to facilitate Mail routing between different
     locations.  Most mail traveling outside of its own area will bear an
     address consisting of a name and domain.  The main backbones of the C86Net
     carrying the mail will know how to get to the domains registered with the
     network, and thus the Mail will get delivered.

        Second, it uses them to make maintenance of large nodes of lists on
     installations far easier and convenient.  A large node list makes it
     easier for users to send mail without having to necessarily worry about
     knowing what domain a system resides in, but can slow down systems.
     Therefore, Citadel-86 supports both "primary" and "secondary" lists of
     nodes.

        The primary node list is the list you construct using either the
     RoutMail utility or Citadel-86's Network Menu 'A' option (see Section
     III.3.a).  Nodes you list on your primary nodelist are valid targets for
     direct Mail delivery, route mail handling, direct room sharing, file
     requests, and file sends.

        A secondary node list consists of one or more files containing system
     names and their associated domains.  These files, located in #NETAREA,
     are named NODES0.FST, NODES1.FST, etc.  Secondary lists are in a special
     format (see UTIL3.MAN on 2ndFmt.Exe) which lets Citadel-86 quickly look
     up names.  On the main C86Net, acquisition of one of these lists can be
     automated in cooperation with your local domain server.  Secondary lists
     let users send mail without undue inconvenience, while not burdening
     installations with large primary node lists, by looking up a system
     name in the secondary list and automatically assigning the proper domain
     name to it, rather than forcing the user to explicitly state what it
     is.

        Third, Citadel-86 allows users to send mail explicitly to systems
     which the current installation knows nothing about.  Users may specify
     a system and domain address which the current system knows nothing
     about, yet C86Net will still try to deliver the Mail on the assumption
     other systems on the net may have a better idea how to get to the
     given system.  Users use this explicit method by typing .EN at the
     Mail> prompt and entering the address as "system _ domain" or
     "system.domain".

     V.3 Practical Notes and Procedures for all systems
        This section describes what every Citadel-86 must do to effectively
     participate in domains.  First we'll discuss some CtdlCnfg.Sys


                                   -21-






     parameters and then some suggested procedures.  Notes on being a
     domain server reside in the section following.

        #nodeDomain is a string parameter which identifies which domain you
     are a part of.  You can only belong to one domain at a time.  Before
     setting this parameter you should check with your local backbone
     (which is presumably who you originally made contact with C86Net) so
     you can be part of the domain s/he is serving and get service in that

     way.  If there is no backbone local to you, you may want to become the
     local server (if you can afford making calls or can con some other
     backbone into making calls to you).  The #nodeDomain is transmitted
     with each message originating from your system so other systems on
     the net will know how to send Mail to you (using your system and
     domain to do the addressing).

        #MailHub provides a facility for forwarding domain mail to systems
     which know who serves what domains, so that most of the systems on the
     network need not know who is serving what domain.  Most of the time this
     parameter should be defined to be your local backbone.  Backbones can use
     this, too, to forward to other backbones which may be more knowledgeable
     about the state of the network.

        #DOMAINAREA identifies where the temporary files associated with
     domain mail are stored.  We strongly suggest you not make this the
     same as #NETAREA!

        #DomainDisplay is strictly an optional parameter which you can skip
     over and/or do nothing about if you don't feel like it.  It is provided
     so you can customize what the display of domains will look like on your
     system when your system is displaying foreign messages to users.

        There is a trick to this parameter (and you C programmers will, of
     course, instantly recognize it): This string parameter must have included
     in it somewhere the character sequence "%s".  When this parameter is used
     to display a domain, the "%s" is replaced by the domain name.

        If you don't use this parameter, then the default behavior is to
     display the nodeName/nodeDomain sequence like this:
     ... @nodeName _ nodeDomain. In other words, the default value of
     #DomainDisplay is

         #DomainDisplay " _ %s"

     (Note the leading space.)  This presents an aesthetically pleasing
     appearance and is also compatible with the user interface for specifying
     how to send net mail to an unknown system in another domain.  But, of
     course, some people like to have a different appearance to the domains of
     other messages.  For instance, enclosing the domain name in brackets is
     popular:

         #DomainDisplay " [%s]"

     The maximum length of this parameter is 10 characters.

        The suggested procedure for non-domain servers is to inform your
     local domain server of your existence and ask them to pass on that


                                   -22-






     info to the current domain coordinator (currently, and reluctantly,
     Hue, Jr. @C-86 Test System _ MN).

        Sections V.4 and V.5 concern Domain Servers.  V.6 will be of
     interest to everyone, though.

     V.4 Practical Notes and Procedures for Domain Servers
        First we'll discuss CtdlCnfg.Sys parameters of concern to domain
     servers, then special files needed by domain servers, followed by a note
     on utilities of use to domain servers, and finally some thoughts on
     procedures.

        If you are going to be a domain server (i.e., a system which will
     accept Mail meant for some domain and is responsible for knowing how to
     get to all systems in that domain), you must tell your installation about
     this.  You do this by putting a line like this in your CtdlCnfg.Sys:

        #ServeDomain "<domainname>"

     For instance, Test System has

        #ServeDomain "MN"

        Every piece of Mail addressed to MN will be processed by Test System,
     based on the target name ("Backfence", "Nowhere Land", "DogLink", for
     example), for delivery to their target systems.

        You can serve more than one domain by placing additional #ServeDomain
     parameters in your CtdlCnfg.Sys.

        "Name Resolution", or the identification of which system the mail
     should be delivered to by its name (rather than the far more reliable node
     ID) is a necessity if the Mail is to go through.  Therefore, you should
     make sure the names on your primary node list, which is used to reroute
     the incoming domain mail to your local systems, are simple -- i.e., they
     are the likely form in which incoming Mail will be addressed to.  For
     instance, "Troy City" is a lot easier to deal with than "Troy City NY",
     and the mail will be far more likely to be delivered.

        This is equally applicable to your own #nodeName.

        If you're in one of those rare situations where two names seem equally
     applicable for some system (such as "C-86 Test System" and "Test System"),
     you can use ALIASES.SYS to make an alias.  The format of this file is
     simply

     <alias> <realname>

     where realname is the name in your primary node list, or your own
     #nodeName if you need an alias for yourself (like Test System does).

        Domain Handlers need one special file which local systems don't need.
     CtdlDmhd.Sys, located in your #NETAREA directory, is basically a directory
     of domain servers.  This file is used by Domain Handers to decide how to
     get domain mail to the server for each domain.  For those domain servers
     a system connects directly with, this is very easy.  For such a domain
     for which mail meant for that domain has come into existence (either via


                                   -23-






     netmail from some other system or created on this system), the system
     checks CtdlDmhd.Sys to find the domain server.  It then looks in its
     primary node list to see if it knows more about the domain server in
     question.  When it finds it, it also finds the direct connection, and
     the next time you connect with that system, the mail is delivered.

        The problem is a bit more tricky for domains that are farther away.
     There are two options.  First, CtdlDmhd.Sys can also contain hints about
     how various domains connect to each other.  There may be any number of
     hints.

    A second option is to place relevant domain servers in your nodelist
     and then use the RouteMail utility to set routes up correctly.  For full
     detail, see the section below on the RoutMail utility (V.5).  Please
     note you do NOT need every node listed in CtdlDmhd.Sys also present in
     your primary node list.  The major backbones are responsible for knowing
     how to get to most of the nearby domains, and the hints in CtdlDmhd.Sys
     should ensure mail traveling long network distances should reach their
     destinations.

        Each line of CtdlDmhd.Sys contains information about one of the domains
     and its server, or contains one of the hints.  The structure of each line
     for a domain designation and its server is

        <domain name><space><system name>:<system ID>

        For instance, the line describing C-86 Test System as the MN domain
     server would look like

        MN C-86 Test System : US 612 470 9635

        Please note, however, that this is equally valid:

        MN Test System : US 612 470 9635

        The name field is only used for human reference; the node ID field is
     critical to Citadel-86 for management, so make sure you get it right.  A
     hint line looks like

         <domain id1> via <domain id2>

     which is to be read as "domain Id1 is reached via domain id2."  These
     hints are used to find which system provides the best route to a given
     domain without needing all domain handlers in the primary nodelist.

        A '#' will act as a comment in this file, if you like to comment a
     file like this.

        If you are connecting to the main C86Net network, then in all
     probability you can arrange to have this file updated automatically
     via the backbone you connect with.  See documentation on the 'redirect'
     #event and the Aff.Exe utility.

        However, since CtdlDmhd.Sys distribution can be automated, it may be
     useful to have a second file like CtdlDmhd.Sys.  Therefore, you can set
     up a file named CtdlDmhd.Lcl in your #NETAREA.  Same format as above.
     The purpose for this support is to allow installations to have a local,


                                   -24-






     hand-tailored version of CtdlDmhd.Sys that won't be overwritten by the
     automated distribution system.  Most systems will have no use for this
     capability, but maybe a few will.  Don't sweat it.

        The Aff utility, now that we've mentioned it, is a utility which will
     let you automatically set up file sends depending on whether a given
     file's time stamp indicates it should be sent to a system or not.  See
     UTIL3.MAN for more details.  You should strongly consider using this
     utility to update other domain servers you connect to with new
     CtdlDmhd.Sys files, and your local systems with new NodesX.* files
     (both Nodes0.fst and Nodes0.raw).

        A log file is occasionally generated, called DOMAIN.LOG.  This
     file will usually only contain messages concerning undeliverable
     Mail>.  "Undeliverable mail" is mail addressed to a domain served
     by this system, but the name of the system was unrecognizable.  In
     this case, DOMAIN.LOG will have an entry with the name of the system
     the name is meant for.  If the name appears to be misspelled, or is
     a valid alternative to some system, bringing the system down and
     placing an appropriate entry in ALIASES.SYS.  When the system comes
     back up, it'll rescan the outstanding mail, find the Mail in question,
     find the alternate name and map it to the real name, and set up the
     mail for delivery.

        Those systems which do not have #MailHub settings (very rare)
     will see a second type of message in DOMAIN.LOG.  This message is
     generated when incoming domain mail is addressed to a domain the
     system does not know how to reach.  This can be fixed by adding
     appropriate entries to CtdlDmhd.Sys (or just deleting the mail, if
     you're in a bad mood), or changing the entry in MAP.SYS in the domains
     directory (if the domain designation is simply wrong or is garbage).
     Such undeliverable mail, however, will usually accumulate on one system
     on the network.

        Finally, concerning procedures, Hue, Jr. @ C-86 Test System _ MN
     is currently the acting central domain registration and management point
     for domain information, so you should contact him if you either want to
     act as a domain server or if you happen to connect to some different
     domain servers and think you may be the only connection to them.  Through
     fortuitous use of the 'redirect' #event on your part and the Aff
     utility on the part of whoever your local domain server is (or major
     backbone or however you get to Arcadia), you can have each new version
     of Ctdldmhd.sys forwarded to you.

     V.5 RoutMail

        The ROUTMAIL utility is fully described in UTIL3.MAN.  The domain
     server, however, really only needs this to know this: you can use
     ROUTMAIL to automatically update your primary nodelist with all the
     domain servers on the net (using CtdlDmhd.Sys), and any links you need
     in order to get to them (which will typically already be in place
     anyways).  In order to perform this operation, you need CtdlDmhd.Sys
     and the latest RoutMail map (obtainable from the backbone which leads
     to Arcadia from where you live).  Once you have them, you need only





                                   -25-






     type "ROUTMAIL +domains <map file name>", and the system should

       a) Add all the domain servers to the list
       b) Add whatever other systems are needed to get to the domain servers
       c) Set the routing pointers so your system knows how to get to
           other domain servers without calling them directly.

        Please note only major backbones or domain servers which directly
     connect to several domain servers will need to use this feature.
     Those servers which are on the more outlying parts of the net can
     probably let #MailHub serve their needs quite well for those domains
     they don't connect with directly.

        If you do look at ROUTMAIL more closely, you'll notice you can define
     routes to other systems (by pointing at the next system on the path to
     them).  You can use this ability in conjunction with domain mail to
     deliver Mail to a local system, if, for instance, the system is on limited
     hours and someone else is better able to get to that system.  It won't
     interfere with domain mail.

     V.6 Costing

        Specific "costs", measured in LD credits, can be set on a domain by
     domain basis.  This is done via the file CtdlCost.Sys, which is a text
     file located in your #NETAREA directory.  The file is a collection of
     entries, each one setting the "cost" to be inflicted on users wishing to
     reach systems in those domains.  The format is simple:

        <domain name><space><cost>

        For example, to set a cost of 2 credits to send mail to domain IL,
     you'd have

        IL 2

        There is also a "special" domain name, "Unknown".  This one lets you
     set a domain cost for those domains which users can specify but are not
     listed in this file.  If you want to set this at 1, you'd have

        Unknown 1

        Citadel-86 sysops can use Ease to manage this, rather than directly
     edit the file.

        Users are assigned LD credits via the Sysop's Network menu (^L-N),
     using the <C>redit option.

        It's feasible to set costs at 0 for domains (and in fact is recommended
     for your own domain [#nodeDomain]), but for those outside of your
     immediate area you should check with your backbone(s) to make sure they
     don't mind.

        This stuff only applies to mail generated on your own system, not on
     incoming network mail.





                                   -26-






     V.7 NodesX.*

        This section more fully describes the NodesX.* files.  The "X" is
     really a digit.  All files described herein should reside in your
     #NETAREA directory.

        The NodesX.FST files are the files Citadel-86 considers as the
     secondary node lists which should be searched if a user specifies a
     system not in the primary node lists.  These are specially formatted
     files (generated using 2ndfmt.exe) which lets Citadel-86 quickly
     search for a given file name.

        The reason they are numbered (Nodes0.fst, Nodes1.fst, etc.) is to
     give sysops more flexibility.  Main C86Net will be trying to supply
     Nodes0.* on an automatic basis to all interested systems.  However, some
     systems may find they want to connect some systems not generally
     available.  Or not.  There is not necessarily any real use for this
     additional flexibility.

        The NodesX.RAW files are the files from which the NodesX.FST files
     were generated.  While the FST files are good for searching for names,
     they are horrid for display purposes, and displaying lists of system
     names is important to users, sometimes.  Therefore, those system
     which want to provide the service of responding in a full manner to
     .EN? and the like should arrange to have the NodesX.RAW files
     delivered along with the NodesX.FST files, on the same automated basis.

     V.8 Technical Notes
        This section describes domain mail storage.  Domain mail is stored
     in the #DOMAINAREA directory.  Within this directory will exist a
     file named MAP.SYS and zero or more directories.  Each directory
     will contain the domain mail which still needs to be delivered
     to the domain server for that domain (whether through direct delivery
     or indirect delivery).  Domain mail is encrypted.

        MAP.SYS is simply a mapping from the names of the directorys to
     the name of the domains they serve.  The third field of each line
     is simply the next file name to use in that directory for incoming
     mail.

     VI. STadel mail routing
        Citadel-86's RouteMail is not directly compatible with STadel's
     mail routing.  However, Citadel-86 is capable, with proper
     coaxing, of generating and accepting STadel-compatible (more or
     less) route mail and delivering the mail to the intended system
     and recipient.

        The procedure is not completely trivial and, due to the nature
     of STadel route mail, it is time consuming.  Areas in which there
     are several Citadel-86 installations may benefit from designating
     a single system as the 'gateway' into the STadel mail routing and
     forcing all the other systems which need to route into the STadel
     network to go through the gateway system.  This is not to imply
     all mail traffic between STadels and Citadel-86s should be
     restricted to a single bottleneck; systems local to each other should
     certainly retain their current direct links.  However, when a
     non-local STadel is the target of some mail, directing the mail to go


                                   -27-






     through the 'gateway' system may minimalize the work of all the
     sysops except the gateway sysop.  But this is only a speculative
     suggestion.

        As a general note, STadels can be listed in the domain maps and even
     exist as domain servers (such as undermind for GA).

        There are some limitations to the gateway.  The most important one
     which leaps to mind is that since STadel does not support the 'W'ho
     else feature of Citadel-86, any use of mail routing involving 'W'ho
     else (both explicit routing and Mail Forwarding) will result in
     delivery of the mail only to the primary recipient of the mail on
     the target system, and no one else.

        The following subsections detail what actions are necessary
     for supporting a gateway between C86Net RouteMail and STadel mail
     routing.

     VI.1 Outgoing mail routing
        In order to understand what we need to do in order to have an
     effective gateway, a rudimentary explanation of STadel mail routing
     is in order.  In brief, a mail message which is to be routed has a
     modified recipient field.  Rather than just being "Joe Blow", such
     a message is of the form "<system>![<system>!...]<username>".  In
     English, an STadel mail message is routed using the recipient field,
     which will consist of one or more system names separated by
     exclamation points.  The last name will be the recipient's name.
     An example might be "Msg Port!The_Land!sysop".  This also applies to
     domains.  For instance, "undermind.ga!cmc" is a valid address.

        The important point is STadel is dependent on the exact node
     Names* to be specified.  To use one infamous example, "Backfence" is not
     the same as "Backfence [MN]"; nor is it likely STadel sysops
     will be willing to use some of the more convoluted names in
     use on some Citadel-86 installations.  So, in order to use STadel
     mail routing, the exact names must be available in some form or
     another.  This is where things become laborious.  The sysop who
     wishes to have a gateway available into the the STadel net must do
     one of two things: either change all nodes in his nodelist so
     the Name field matches whatever the STadels are using to designate
     your system, or create a file in your #ROOMAREA directory named
     ALIASES.SYS.  Each line in the file is in the form of

        <STadel name> <node name from your node list>

        Citadel-86 will use this list to translate as necessary from your
     own nodelist to the STadel list (and vice versa, in the next section).
     For instance, if you have the Minnesota system Class of 68s in your
     nodelist, and must route to it via STadels (rather than via C86Net
     RouteMail), you would have to have the line

        Class68 Class of 68s

        The first word in the line is the name of the STadel node in STadel
     lingo, and can ONLY consist of one word.  If the STadels are using
     spaces (very rare) in the some system name, then replace the spaces with
     underscores ('_').  The balance of the line contains your name for the


                                   -28-






     node -- that is, the name assigned in your nodelist.

        Note that if you really don't want to maintain an ALIASES.SYS file,
     all you need to do is modify your nodelist to use the same names
     as STadel sysops are using.  In this instance, you'd change 'Class
     of 68s' to 'Class68'.  This is highly recommended.

        These notes are also valid in the situation in which a Citadel-86 is
     routing to another Citadel-86, but must use one or more STadels in the
     route to it.  For instance, Test System in the Twin Cities and Circus in
     Edmonton are both Citadel-86 systems, but the link between the two
     systems is Secret Service ('secret'), an STadel.  In order for Test
     System to route to Circus (either for itself or for other systems), it
     must either have Secret Service listed as 'secret' in its node list, or
     it must have an entry in ALIASES.SYS which would look like

        secret Secret Service

     (assuming secret's name in Test System's node list is 'Secret Service'),
     and it must have Circus listed as 'Circus' in its nodelist (not
     'Circus_Edm') or an entry in ALIASES.SYS:

        circus Circus_Edm

        Also, in order for a system to be a gateway into STadel mail routing,
     the nodes(s) which will be used to gain access to the STadel mail routing
     must be marked as STadels (note this does not at all imply ALL STadels
     must be marked, however -- only those which the gateway system will be
     using to route into the STadel mail network).  This new field defaults
     to OFF when an entry is added to the nodelist, so if you need to use a
     system as the STadel gateway, you'll have to change that field.  Use
     RoutMail +manual to do so (make sure you have v1.7) -- the field should
     show up in the lower right hand column of values.

        Finally, domain mail can be routed in STadel land.  It'll simply
     be sent as "<system>.<domain>!<user>".

     VI.2 Incoming route mail
        There are similar problems in handling incoming mail, to wit, name
     mismatches.  Once again, ALIASES.SYS is used to help resolve these
     problems.  It cannot be guaranteed that STadels will use the same
     spellings as Citadel-86 systems will for nodenames, so entries in
     ALIASES.SYS will be scanned when necessary in order to find the
     'real' names (that is, the name the C86 is using) of systems
     when trying to decode incoming mail for delivery to those systems.

        This problem may include your OWN system.  Mail delivered to your
     own system directly by an STadel will almost certainly be of the form
     <system name>!<recipient>.  The problem is your system won't
     realize the mail is meant for your system unless it recognizes
     "system name" as being the same as your #nodeName parameter.  However,
     once again, STadels may not spell your #nodeName as you have yourself,
     or you may change yours' at some point.  Therefore, it is perfectly
     valid to have an entry in your ALIASES.SYS specifying how the STadels
     are spelling your #nodeName.  Simply make sure you spell your entry
     exactly how you spelled your #nodeName.  For instance, Test System's
     "formal" #nodeName is "C-86 Test System".  But STadels may choose to


                                   -29-






     simply have "Test System".  The entry in ALIASES.SYS would then
     be

        Test_System C-86 Test System

     VI.3 STadel considerations
        There are some other problems to be considered, and we're not
     sure we're aware of all of them.  The main problem is how to ensure
     mail being routed into the STadel mail system will make it to the
     target system.  STadel is apparently capable of some simple
     rerouting when necessary, but it is not automatic.  When attempting
     to set up a gateway in your area, you will probably have to work
     closely with the STadel sysop.  The reason for this is Citadel-86
     will only generate target paths that look like this:

        <gateway system name>!<target system name>!<username>

        This could prove a problem when the target system is actually
     several 'hops' away on the network, and in fact would result in
     the loss of the mail.  However, as I understand it, STadel sysops
     have some ability to cause such mail to be rerouted, in other words,
     replace the given path with a path more likely to succeed.  When
     working to set up a gateway which will be used for extensive mail,
     make sure to mention this concern to the other sysop.  This problem
     is not of as great a magnitude, however, when dealing with isolated
     STadels which simply wish to piggy-back onto C86Net RouteMail.

         Note that domain mail probably doesn't suffer from this problem.

     VI.4 Notes

        o Remember to set the STadel node in your list you'll be using to
     gate the STadel system as an STadel, using RoutMail +manual.  Not all
     STadels you net with, directly or indirectly, need this setting
     (although it doesn't hurt), only those which you'll be using to route
     mail to other systems.

        o Remember, each system in your nodelist has two flags associated
     with it, indicating whether you're willing to route mail to it.  They
     apply to STadel routing as well as C86Net RouteMail.   Make sure they
     are turned on for those nodes you're willing to route to/from.

        o Make sure the STadel sysop knows about your concerns regarding
     rerouting on his side.

        o There may be limited error detection available in Citadel-86 vis
     a' vis undeliverable mail.

     VII. CTDLCNFG.SYS Parameters
        There are several parameters in CTDLCNFG.SYS that help you control what
     Citadel-86 will do with the network.  All of these parameters were covered
     in the Citadel-86 Installation Manual, but we shall cover them again here.

        The #NETWORK parameter is the basic parameter that decides if you are a
     networking system or not.  A numeric value of 1 indicates that you are;
     0 indicates no.



                                   -30-






        The #RouteMail parameter allows you to select or deselect mail
     routing.  If you set this parameter to 0, then you categorically refuse
     to route any mail anywhere.  The default of this parameter is 1, however.

        The #NewNetPrivs lets you decide whether or not new users automatically
     gain net privileges on login.  1 indicates yes, 0 indicates no (a good
     paranoid value).

        The #NETAREA parameter indicates where CTDLNET.SYS and nearly all
     temporary (the only exception being domain files) network files should
     reside on your system.  It is just like #MSGAREA, etc., specifying a
     directory for the location of files.  CTDLNET.SYS may be large, depending
     on how many nodes you have and the values of two parameters that follow
     this one, but the temporary files very rarely exceed 1K, and usually are
     short-lived (except for the *.VEX files, which are always there, if they
     are there at all).

        #SHARED-ROOMS indicates the maximum number of rooms that you think
     you'll ever share with another system simultaneously.

        #NET_RECEPT_AREA designates the area on your system that files that
     were sent to you with the Send File facility (Section III.3.f) should be
     placed. This may be anywhere on your system.

        #NET_AREA_SIZE specifies the maximum number of bytes that may occupy
     the #NET_RECEPT_AREA directory at any one time, which provides you with
     a way of keeping your system from being flooded.

        #MAX_NET_FILE specifies the maximum size of any single file to be
     received from the network via the Send File option (see Section III.3.f).
     If you don't want monster files sent to you, here is your solution.

        #callOutPrefix is a string value that tells the modem to prepare to
     dial out.  For Hayes/compatibles, this is usually "ATDT".

        #callOutSuffix is a string value that tells the modem that all the
     information that it needs to dial has been sent to it.  For
     Hayes/compatibles, this is usually "\r".

         #DialOut300, #DialOut1200, #DialOut2400, #DialOut4800, #DialOut9600,
     #DialOut14400, and #DialOut19200 can each be used to override the value
     of #callOutPrefix.  This is useful with USR HST modems and their ilk.

     Appendix A: Other room-based Networks

     HengeNet: This network is for the StoneHenges.  The last news I heard
     was that the homebase of the Stonehenges, CKMCMS, was down.

     CitaNet: The exact nature of this network is not clear, but seems to be
     semi-manual and is used by the K2NE (Commodore 128) systems, along with
     one or two Citadel-86 systems and possibly others.  Homebase for this net
     is Vince Quaresima of The Jersey Devil ([phone]).

     MacCitadel: These systems have a network of some sort.  MacCitadel's
     home base is ??????????????




                                   -31-






     Appendix B: Temporary Files

        Citadel-86 generates and destroys temporary files in order to service
     C86Net.  All of these files are placed in the directory specified by the
     CTDLCNFG.SYS parameter #NETAREA, and most should not last past the next
     networking session once generated.

        Most are of the form <numeric>.<ext>.  The numeric value is the
     position that the relevant node occupies in CTDLNET.SYS; ext indicates the
     purpose of the temporary file.  The current ext values currently used are:

      ML  = Mail file
      RFL = Request Files
      SFL = Send Files

        Thus, the file 12.ML contains the data necessary to send net Mail> to
     the twelfth system on your netlist.

        Additionally, from time to time files of the form "R<num>.<num>" will
     appear and disappear from the directory.  The R means they are Route Mail
     temporary files; the first 'num' refers to the node the mail is being
     sent to on its way to its destination (the routing node), while the
     second num is just a sequence (housekeeping) number for internal use.
     Please avoid deleting these files, and don't try to read them - they are
     private mail and should be treated as such.

        Domain Mail also requires temporary files, but they are confined to
     #DOMAINAREA, so don't worry about them too much unless some persist.

     Appendix C: Main C86Net
        The main C86Net is an international net with nodes scattered
     throughout the United States and Canada.  Homebase for the main C86Net is
     Test System @ [phone], but there may be a system near you on the
     net, particularly in the northern half of the United States.

    The following is a list of BBS packages known to be compatible, more
     or less, with C86Net.  In most cases these packages are derivative of
     Citadel-86.

    Citadel-86    (PClones)
    Citadel 68K   (Amiga)
    STadel        (Atari ST)
    NeoCitadel    (PClones)
    Citadel-86e   (PClones)
    Fortress      (PClones)
    <fnord>adel   (Atari ST)
    b0badel       (Atari ST)
    Asgard-86     (PClones)
    Citadel-86/TI (TI PC)
    Citadel:K2NE  (PClones)









                                   -32-






     Appendix D: RoutMail.Exe
        The RoutMail utility, as noted in UTIL3.MAN, can be used to edit the
     node list as well as ingest mail routing maps.  Simply type

        ROUTMAIL +manual

     and you will be presented (sooner or later) with a list of nodes which you
     may select using cursor keys.  Selecting one allows you to edit all (?)
     parameters associated with a node, except for the rooms shared.  Note
     that the node editing capabilities in Ctdl.Exe are NOT complete any
     longer, and some thought is being given to placing all responsibility for
     node editing in RoutMail.  In particular, the routing and STadel flags are
     only accessible via RoutMail as of this writing (this may change in the
     future, however).













































                                   -33-